[Previous] [Next] [Index] [Thread]

Re: some questions about SHTTP

Wang Wei Jun said:
> If that's the case, shall we start discussing it? At least the implementers
> should let others know what is changed/unsaid in the spec. Otherwise, we
> may just have a lot of 'SHTTP compliant' client/servers but they won't talk
> to each others. This really defeats the purpose of WWW.

Very much so, yes, particularly if we really want SHTTP to be a
standards-track protocol.

> (BTW, is there any email group specifically discuss SHTTP?)

There's shttp-talk@openmarket.com, but there's never any traffic on it.
This group is probably as good a place as any, since theoretically it's the
group of the IETF WG for the spec.

> > Was anybody actually using it?  If not, it seems implausible that anybody
> > will anytime real soon.  PGP is not available inside the U.S. for commercial
> > use under reasonable terms, so I wouldn't expect to see anything happen with
> > it here.
> > 
> Yes, people outside USA are using PGP. So in order to let us use SHTTP,
> it's good if the spec. can include PGP support.

I mean, was anybody actually using PGP in SHTTP implementations?  I know lots
of people are using it for mail and stuff.  PGP was in the spec for a long
time, and nobody really used it.  In the long run, it's obviously necessary
to have common formats that everybody uses in order to get anywhere with this.
I suspect that long-term winner will be PKCS7 due to its flexibility and
compactness (despite the fact that many existing implementations make a
mockery of that compactness by base64 encoding it.)

> > I believe it is not encrypted at all under any key.  The real question is,
> > why wrap an unencrypted message in PKCS-7 and base64 encode it instead of
> > just sending it with no Content-Privacy-Domain at all?
> > 
> If that's the case, then it will be contradictory to section2.3.5 MAC-Info.
> (suppose <Key-ID> has the same interpretation as 'dek'.) because if the key
> is specified, then the message must be encrypted. The spec. says: (it is
> an error to use this key-spec in situations where the folowing message
> body is unencrypted).

But the example does not use the "dek" key-spec, it uses the "inband:alice1"
key-spec, which is legal as long as the context has defined an inband key
named alice1 (e.g. the previous message contained an appropriate Key-Assign:
header.)

- Marc
References: